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SECTION  1 


INTRODUCTION 


This  report  examines  the  NSS,  a  commercially  available  family  of  products  designed  to 
resolve  important  network  security  concerns.  Fundamental  features  and  fimctionality  of  the 
Semaphore  NSS  are  identified,  followed  by  details  of  assessment  testing,  including  test 
descriptions  and  test  results.  A  sununary  of  test  results  and  reconunendations  for  future 
assessment  is  also  presented. 

1.1  BACKGROUND 

Modem  networks  of  distributed  client-server  architectures  have  contributed  largely  to  the 
increased  need  for  network  security.  Client-server  architectures  are  extremely  popular 
because  they  promote  resource  sharing  among  networked  computer  users.  Relationships 
between  users  and  services  are  defined  such  that  commonly  us^  services  are  easily 
accessible  to  a  wide  range  of  authorized  users.  This  design,  however,  also  increases  the 
number  of  network  access  points  available  to  introders  or  other  undesirables.  Therefore, 
malicious  attacks  on  the  network  such  as  network  eavesdropping  and  computer  address 
spoofing,  are  often  simple  to  execute  without  detection.  The  large  number  of  computer 
break-ins  through  client-server  networks  are  convincing  evidence  that  networked  systems 
needs  stronger  protection  against  access  by  unauthorized  sources.  As  a  result,  network 
security  is  a  primary  concern  for  modem  computer  networks. 

Network  security  addresses  the  protection  of  computer  information  as  it  is  sent  across  die 
network  fi-om  one  computa*  to  another.  For  example,  how  to  protect  identification  and 
authentication  data  (e.g.,  user  IDs  and  passwords)  exchanged  between  computers  across  the 
networi^  is  a  recurring  network  security  issue.  Private  and  sensitive  information  traversing  a 
network  must  be  protected  against  unauthorized  disclosure  and/or  modification  as  it  travels 
between  computers.  The  Senu^hore  NSS  is  one  of  a  numbo*  of  commercially  available 
software  and  hardware  products  that  have  recently  emerged  as  a  potential  solution  to  such 
network  security  problems. 
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SECTION! 


PRODUCT  DESCRIPTION 


The  Semaphore  NSS  is  a  family  of  five  products  that  includes  four  classes  of  Network 
Encryption  Units  (NEUs)  and  a  Networit  Security  Center  (NSC).  NEU  classes  include  a 
personal  computer  encryption  unit  (NEU-PC)  that  protects  an  individual  node,  a  work  group 
encryption  unit  (NEU-WG)  that  can  protect  a  group  of  up  to  fifteen  nodes,  a  hub  encryption 
unit  (NEU-HB)  that  can  protect  a  building  or  department  of  up  to  180  nodes,  and  site 
encryption  units  (NEU-ST,  NEU-RT)  that  can  be  placed  at  a  router  to  protect  all  data  leaving 
a  geographic  site.  Each  NEU  contains  a  32-bit  Reduced  instmetion  Set  Computer  (RISC) 
processor  and  includes  a  datakey  receptacle  for  NEU  initialization.  The  NEU-PC,  NEU-WG, 
and  NEU-HB  each  contain  two  Attachment  Unit  Interfaces  (AUIs)  for  connecting  to  Ethernet 
or  ISO  8802.3  Local  Area  Networks  (LAN).  The  NEU-ST  supports  serial  V.35  network 
interfaces,  whereas  the  NEU-RT  supports  SEE  802.3.  NEUs  are  connected  to  LANs 
between  the  network  and  the  node(s)  whose  data  it  will  protect  Nodes  are  de^ed  as  devices 
connected  to  the  LAN  such  as  workstations,  PCs,  and  printers. 

An  example  configuration  of  the  NEU-WG^  unit  is  shown  in  Figure  1.  The  figure  illustrates 
how  the  woik  group  unit  may  be  networked  to  protect  multiple  nodes  and  indicates  NSS 
simultaneous  support  for  multiple  protocols. 
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Figure  1.  NEU-WG  Network  Configuration 


1  This  report  is  based  on  an  assessment  of  the  NEU-WG  unit,  as  it  was  the  only  unit 
available  for  testing  at  the  time  of  this  writing. 
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2.1  NETWORK  SECURITY  CENTER 


The  NSC  provides  a  centralized  access  control  database  and  a  distributed  certification 
mechanism  used  for  authenticating  interaction  between  NEUs.  The  NSC  is  required  for  NEU 
initialization,  key  management,  network  auditing,  and  managing  network  access. 

The  NSC  hardware  is  an  IBM  PC/AT  or  compatible,  and  the  NSC  triplication  software  runs  on 
Version  2.0  of  the  OS/2  operating  system.  Minimum  hardware  requirements  for  NSC 
operation  includes  a  33  MHz  clock,  16  MB  of  RAM,  200  MB  of  hard  disk,  a  3.5-inch  floppy 
drive,  a  Super  Video  Graphics  Adaptor  (SGVA)  color  monitor,  a  parallel  port  for  a  printer,  and 
a  serial  port  to  connect  the  datakey  loader.  The  units  are  shipped  with  six  blank  datakeys. 

The  datakey  loader  is  used  for  programming  or  loading  NSC  and  NEU  access  datakeys. 

NSC  access  keys  (NAKs)  are  programmed  during  NSC  software  installation  to  provide 
authenticated  access  to  the  NSC  application  software.  Three  types  of  NEU  access  keys  may 
be  loaded  after  NSC  conEguration  is  completed.  NEU  initiali^tion  keys  (INKs)  are  required 
to  establish  autiientication  of  each  NEU  to  the  NSC  prior  to  NEU  network  communication. 
Configuration  of  either  of  the  other  two  NEU  access  keys,  the  cypto  ignition  key  (CIK)  and 
die  front  panel  key  (FPK)  is  required.  The  configuration  and  the  use  of  optional  keys  is 
described  later  in  the  section  entitled  NEU  Operational  Modes. 

2.1.1  NSS  Configuration 

All  NSS  configuration  is  performed  at  the  NSC.  The  OS/2  operating  system  provides  a  user 
friendly  graphical  interface  for  configuring  the  secure  network.  Access  control  information 
for  each  NEU  must  be  configured;  data  is  entered  to  identify  the  NSC,  NEUs  on  the  network, 
nodes  to  be  protected,  the  level  of  security  protection  for  each  node,  NEU  communities  of 
interest,  protocols  to  interpret,  and  NEU  access  keys  to  be  created.  One  NEU  must  be 
configined  as  the  “NSC  NEU”  and  is  dedicated  for  use  by  the  NSC.  An  abbreviated 
pull-down  map  of  the  main  NSC  configuration  menu  is  shown  in  Figure  2. 

NSS  configuration  begins  with  the  configuration  of  high-and  low-level  entities.  High-level 
entities  are  network  nodes  such  as  workstations,  printers,  or  servers  that  need  cryptographic 
network  protection  and  as  such  are  designated  protected  network  nodes  (PNNs).  The  name 
and  security  protection  level  (i.e.,  encrypt,  bypass)  for  each  PNN  is  entered  under  the 
high-level  entities  menu  command.  The  NSC  and  NEUs  are  also  considered  high-level 
entities.  Low-level  entities  refer  to  protocols  and  addresses  of  PNNs.  Information  for  these 
«itities  are  entered  undo:  the  low-level  entities  command  menu.  Mappings  between  high  and 
low  oitities  are  subsequently  established  using  the  relationships  menu.  Individual  entity  and 
networir  summary  reports  can  be  generated  from  the  reports  menu  and  are  useful  for 
voifying  the  current  configuration.  The  status  of  each  NEU  can  be  obtained  via  the  status 
menu,  and  reports  on  audit  events  may  be  selected  from  the  audit  trail  menu.  The  other 
command  menu  is  used  primarily  to  change  the  default  system  settings  and  to  log  out  of  the 
NSC  tq>plication. 
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Figure  2.  Network  Security  Center  Configuration  Menu 


After  configuration  information  is  determined  to  be  accurate,  datakeys  must  be  programmed 
for  the  NEUs.  The  keys  menu  is  used  for  programming  or  loading  datakeys.  The  first 
configuration  datakey  to  load  will  be  the  NSC  NEU  initialization  key.  No  other  NEU 
initialization  key  may  be  loaded  until  the  NSC  NEU  is  initialized  and  online.  Once  the  NSC 
NEU  is  initialize  and  operational,  other  NEU  initialization  keys  may  be  programmed  and 
other  NEUs  may  be  initialized. 


22  NEU  INITIALIZATION 

Each  NEU  INK  contains  a  Data  Encryption  Standard  (DES)  traffic  encryption  key  (TEK) 
and  network  addressing  information  (NSC,  NEU,  and  router  addresses)  required  for  network 
connectivity  between  the  NEU  and  the  NSC.  An  NEU  must  be  physically  attached  to  the 
network  and  capable  of  communicating  with  the  NSC  for  initialization  to  successfully 
complete.  NEU  initialization  is  started  by  inserting,  turning,  and  then  removing  its  IMC  as 
prompted  by  the  NEU  display.  During  initialization,  each  NEU  generates  Rivest,  Shamir, 
and  Adleman  (RS  A)  public  and  private  keys  and  a  unique  RS  A  digital  ID  certificate. 

A  combination  of  RS  A  and  DES  cryptographic  keying  technology  is  employed  at  NEU 
initialization  to  implement  security  for  the  network.  RS  A  cryptographic  keys  are  used  for 
network  authentication  and  key  distribution.  All  other  network  traffic  is  encrypted  with  DES 
TEKs.  RS  A  encryption  incorporates  a  central  certification  authority  that  validates  ID 
certificates  for  use  on  the  network;  the  NSC  is  the  cotifying  authority  for  the  NSS.  Each 
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NEU‘generated  ID  certificate  contains  its  RSA  public  key  and  is  validated  by  obtaining  the 
RS  A  cryptographic  signature  of  the  NSC.  The  DES  TEK  on  the  NEU  INK  is  used  to  secure 
the  initial  tran^ort  of  the  unsigned  ID  certificate  from  the  NEU  to  the  NSC  for  certification. 
The  signed  cer^cate  is  returned  to  the  NEU  authorizing  it  for  secure  communication  with 
otiier  NEUs.  Key  management  and  distribution  is  thereafter  placed  into  each  NEU. 
Successful  completion  of  NEU  initialization  establishes  “network  authentication"  and 
“automated  and  distributed  key  management"  among  NEUs.  The  steps  for  completing  NEU 
initialization  are  illustrated  in  Figures  3, 4,  and  5. 


23  NETWORK  AUTHENTICATION 

Network  authentication  is  described  in  Figure  3  by  depicting  the  ID  certification  process. 
Hgure  3  shows  a  single  PNN  NEU  and  the  NSC  NEU  connected  via  a  LAN.  The 
PNN  NEU  ID  certificate  needs  to  be  certified.  Each  NEU  encrypts  its  RSA  ID  certificate 
with  the  DES  traffic  encryption  key  received  from  its  INK.  The  encrypted  ID  certificate 
is  sent  across  the  network  fi:om  the  NEU  to  the  NSC.  The  NSC  decrypts  the  NEU  ID 
certificate  using  the  shared  DES  traffic  encryption  key  and  then,  as  the  certifying  authority, 
cryptographically  signs  the  NEU  ID  certificate  with  its  NSC  RSA  private  key.  The  signed  ID 
certificate  is  returned  to  the  NEU.  The  NEU  now  has  credentials  for  authenticated  network 
communication  to  other  NEUs. 
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2.4  AUTOMATED  AND  DISTRIBUTED  KEY  MANAGEMENT 

The  NSC-certified  ID  certificate  and  the  RSA  keys  generated  by  each  NEU  are  used  to 
automate  and  secure  the  distribution  of  DES  TEl^  between  NEU  pairs.  Each  NEU 
automatically  negotiates  and  generates  a  DES  TEK  for  each  NEU  with  which  it  wishes  to 
communicate.  DES  TEK  distribution  is  negotiated  between  NEUs  by  an  RSA  cryptographic 
exchange  of  an  NEU  randomly  generated  check  value.  The  RSA  verified  check  value  is  used 
to  authenticate  the  receipt  of  I^U-generated  DES  TEKs  from  the  network. 

After  receiving  its  authenticated  ID  certificate  (as  shown  in  Figure  3),  each  NEU  first 
negotiates  with  the  NSC  NEU  to  create  a  new  DES  traffic  encryption  key  to  be  shared  only 
between  it  and  the  NSC  NEU.  Negotiation  for  key  distribution  is  indicated  in  Steps  5 
through  10  of  the  NEU  initialization  process  as  illustrated  in  Figures  4  and  S. 
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Figure  4.  NEU  Initialization;  Request  for  Key  Negotiation 
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Figure  5.  NEU  Initialization:  TEK  Generation  and  Download  of  NEU  Connection  Table 


In  Hgure  4,  the  NEU  sends  its  ID  certificate  widi  a  request  for  key  negotiation  to  the 
NSC  NEU.  The  NSC  NEU  verifies  the  NEU  ID  cotificate  and  sends  back  its  own  ID 
certificate  and  a  random  check  value  encrypted  in  the  NEU’s  public  key.  The  NEU  verifies 
the  NSC  NEU’s  ID  certificate,  decrypts  the  check  value,  reencrypts  the  check  value  in  the 
NSC  NEU’s  public  key,  creates  a  DES  TEK  also  «icrypted  in  the  NSC  NEU’s  public  key, 
and  sends  the  encrypted  check  value  and  DES  TEK  to  Ae  NSC  NEU.  After  verifying  the 
check  value,  the  NSC  NEU  stores  the  DES  TEK  received  in  its  “cormection  table.” 

NEU  access  controls  are  specified  in  coruiection  tables  generated  by  the  NSC  as  part  of  NEU 
configuration.  Connection  tables  contain  NEU  source  and  destination  address  pairs  that  tell 
each  NEU  with  whom  it  is  allowed  to  communicate.  Initially,  NEU  connection  tables  reside 
only  on  the  NSC.  However,  each  NEU  needs  this  information  to  establish  independent  key 
management  and  distribution.  Because  the  connection  table  contains  sensitive  information, 
die  download  of  the  table  fi*om  the  NSC  to  the  NEU  must  be  secured.  DES  TEKs  stored  in 
die  NSC  NEU  connection  table  are  used  to  secure  the  download  of  the  connection  table  from 
the  NSC  to  the  NEUs. 

Once  an  NEU  has  its  connection  tables,  it  then  negotiates  the  creation  and  transport  of  a 
DES  TEK  with  each  destination  NEU  identified  in  its  table.  Each  NEU  generates  a  DES 


8 


TEK  to  use  for  securing  communication  between  destination  NEUs  configured  in  its 
connection  table.  Each  DES  TEK  distributed  to  a  destination  NEU  is  stored  in  the  receiving 
NEU’s  connection  table  until  needed  for  encrypting  or  decrypting  traffic  between  that  NEU 
pair.  Key  management  and  distribution  is  automated  as  each  NEU  has  the  means  to  perform 
these  functions  both  securely  and  independently. 


2S  NEU-TO-NEU  ACCESS  CONTROL 

As  previously  discussed,  each  NEU  determines  with  whom  (other  NEUs)  it  can  communicate 
from  access  control  information  received  in  its  connection  table.  The  procedure  for 
establishing  secure  communications  between  NEUs  begins  again  with  Step  5  as  shown  in 
Hgures  4  and  S.  To  conununicate  with  another  NEU,  a  local  NEU  sends  its  ED  certificate  to 
that  remote  NEU.  The  remote  NEU  verifies  the  ID  certifrcate  using  the  central  authority’s 
(NSC)  public  key.  The  remote  NEU  then  sends  its  ID  certificate  back  along  with  a  random 
check  value  encrypted  in  the  local  NEU’s  public  key.  The  local  NEU  checks  the 
authentication  of  the  remote  NEU’s  ED  certificate  using  the  NSC’s  pubUc  key.  When  the 
local  NEU  is  satisfied  that  the  remote  NEU’s  (^rtificate  is  authentic,  it  decrypts  the  check 
value  received  and  reencrypts  it  using  the  remote  NEU’s  pubhc  key.  The  local  NEU  then 
sends  the  remote  NEU  the  encrypted  check  value  and  a  newly  generated  DES  traffic 
encryption  key  that  it  has  also  encrypted  with  the  remote  NEU’s  public  key.  Only  the  remote 
NEU  will  be  able  to  retrieve  the  encrpyted  DES  key  to  use  for  decrypting  traffic  bccw  m  the 
two  NEUs.  The  remote  NEU  decrypts  the  check  value  and  adds  the  DES  TEK  to  the 
connection  record  for  this  NEU  pair.  Steps  5  thorough  13  are  repeated  for  each  destination 
address  in  each  NEU’s  connection  table.  After  completing  DES  TEK  exchanges  for  aU  host 
in  its  connection  table,  the  NEU  waits  for  data  to  process. 

All  data  entering  the  NEU  through  its  node  interface  is  subjected  to  access  control  checks 
performed  by  the  NEU  and  is  either  encrypted,  discarded,  or  passed  through  onto  the  network 
unencrypted.  Likewise,  data  entering  the  NEU  from  the  network  is  also  checked  and  either 
decrypt^,  discarded,  or  passed  out  unmodified  through  the  node  interface.  Access  control 
checks,  used  to  determine  how  data  is  handled,  are  based  upon  the  assigned  hosts’  addresses 
and  data  transmission  protocols  configured  in  the  NEU  connection  table. 


2.6  HOST-TO-HOST  DATA  FLOW  AND  PROTOCOL  SUPPORT 

The  NEU  provides  a  reasonable  amount  of  flexibility  widi  regard  to  host  system  data  link  and 
netwodc  protocol  support.  The  encryption/decryption  of  aU  valid  data  link  layer  ISO  8802.3 
or  Ethernet  firames  is  supported.  Network  layer  protocols  recognized  by  the  NEU  include 
DOD  IP,  Novell  IPX,  and  DECnet  Phase  IV;  AppleTalk  routing  was  not  available  at  the  time 
of  testing  but  is  now  available.  At  the  link  level,  all  data  above  the  layer  two  typef length 
field  is  encrypyted  and  decrypted  in  conformance  with  the  1EEE-STD<802.10B  frame 
structure  and  the  DES  Clipher  Block  Chaining  (CBC)  mode  defined  in  ANSI-STD-X3.106. 

At  layer  three,  all  data  above  the  layer-three  header  is  encrypted  using  the  DES  CBC  mode. 
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Netwoik  layer  formats  are  modeled  after  lEEE-STD-  802.108.2  The  NEU  interprets 
protocol-type  fields  at  bodi  layers  two  and  three.  To  encrypt  at  the  network  level,  the  NEU 
nnist  be  able  to  distinguish  network  protocols  because  data  fields  are  different  for  different 
protocol  types.  The  NEU  modifies  the  type  field  of  encrypted  frames  or  datagrams  based 
upon  access  control  information  contained  in  its  configuration  tables.  The  protocol-type 
fields  in  conjunction  with  internal  configuration  tables  are  used  by  the  NEU  to  determine 
whether  data  should  be  encrypted,  decrypted,  bypassed,  or  discarded. 

A  heterogeneous  network  supporting  multiple  network  protocols  (IP,  AppleTalk,  and  IPX)  is 
depicted  in  Figure  6.  Typical  host-to-host  data  flows  on  this  network  diagram  occur 
between  hosts  supporting  like  (i.e.,  the  same)  protocols.  For  example,  TCP/IP  users 
exchange  data  across  the  network  with  other  TCP/IP  users,  and  AppleTalk  users 
communicate  across  the  netwoik  only  with  other  AppleTalk  users,  etc.  Each  host  connected 
to  fanout  A  is  configured  as  a  PNN  of  NEU  A.  Likewise,  each  host  connected  to  fanout  B  is 
configured  as  a  PNN  of  NEU  B. 


Figure  6.  Network  Data  Encryption 


2  Sonaphoie  adds  a  security  association  ID  and  a  management-defined  field  (MDF)  to  each 
encrypted  data  packet  as  indicated  by  the  802.  lOB  specification. 

3  Although  this  example  illustrates  encrypted  packet  transformation  for  a  TCP/IP  packet, 

IP  packet  transformation  is  the  same  regardless  of  the  transport  protocol  type  (i.e.,  TCP, 
UDP)  identified  in  the  IP  packet  header. 
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Suppose  that  the  TCP/IP  hosts  (PNNIA  and  PNNIB)  are  required  to  exchange  sensitive 
information  across  die  network.^  To  prevent  disclosure  of  this  data  to  possible  network 
eavesdroppers  attached  to  the  Ethernet  LAN,  it  is  desirable  to  encrypt  all  of  the  data  that  is 
passed  between  these  two  TCP/IP  hosts.  Because  the  NEU  processes  multiple  protocols  and 
different  protection  levels  (i.e.,  encrypt,  bypass),  TCP/IP  packets  may  be  encrypted  while  all 
odier  traffic  is  simply  passed  through. 

In  Hgure  6,  all  data  leaving  Fanout  A  must  pass  through  NEU  A  to  reach  hosts  connected  to 
Fanout  B.  NEU  A  and  NEU  B  have  been  configured  to  encrypt  TCP/IP  packets  and  to 
bypass  (passed  dirough  unencrypted)  AppleTalk  and  IPX;  protocols  that  are  not  configured 
will  be  rejected.  Data  flow  of  a  TCP/EP  packet  (PNNI)  from  host  PNNIA  to  host  PNNIB  is 
as  follows:  PNN 1  leaves  PNNIA  unencrypted  and  arrives  at  NEU  A,  NEU  A  encrypts 
PNNI  and  sends  encrypted  PNNI  across  the  router  to  NEU  B,  NEU  B  decrypts  PNNI  and 
sends  unencrypted  PNNI  to  PNNIB.  NEU  data  encryption  and  decryption  of  packet  PNNI 
is  transparent  to  source  (PNNIA)  and  destination  (PNNIB)  hosts.  De^s  of  NEU  data 
encryption  and  decryption  are  discussed  in  the  next  section  that  describes  the  NEU  to  NEU 
dataflow. 


2.7  NEU-TO-NEU  DATA  FLOW 

As  described  earlier,  the  confrguration  or  coimection  table  of  each  NEU  contains  node 
address  pairs,  a  DES  traffic  encryption  key,  and  several  access  control  variables.  Source 
addresses  in  IP  packets  entering  the  NEU  are  compared  to  NEU  table  addresses.  A  source 
address  found  in  the  table  triggers  further  checks  of  access  control  variables  that  are  used  to 
determine  whether  the  packet  will  be  encrypted  or  simply  passed  onto  the  networic  without 
alteration.  If  a  host  address  is  not  found  in  tiie  table,  tire  packet  is  either  discarded  or  passed 
onto  the  network  in  accordance  witii  confrguration  data. 

When  IP  packet  PNNI  arrives  at  NEU  A,  the  source  address  in  the  packet  is  checked  for 
existence  in  NEU  A’s  coimection  table.  The  source  address  is  identified  and  NEU  A 
determines  that  packet  PNNI  is  to  be  encrypted  based  upon  access  control  variables  for 
source  address  PNNIA.  The  NEU  encryption  process  increases  tiie  length  of  each  packet  by 
placing  a  protected  header  inside  each  packet  Figure  7  illustrates  the  transformation  of 
packet  PNNI  by  the  encrypting  NEU  A. 

The  protocol  field  in  the  unencrypted  (clear)  IP  packet  header  is  modified  by  NEU  A  to 
identify  PNNI  as  a  Senuqihore-encrypted  data  packet  and  to  oisure  that  other  nodes  on  the 
network  discarc  the  encrypted  packet  gracefully.  All  data  above  the  layer-three  header  is 
encrypted  using  tiie  DES  CBC  mode  defined  in  ANSI-STD-X3.106.  The  network  layer 
format  requires  a  Security  Association  ID  and  an  S(X  MDF,  Version  (X)h.  These  fields  are 
clear  data  inserted  into  packet  PNNI  between  the  IP  header  and  the  encrypted  data.  All  other 
data  above  the  IP  header  is  encrypted. 
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DOD  TCP/IP  Datagram 
(Packet)  Transfonnation 
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Figure  7.  NEU  IP-Packet  Transformation 


The  Security  Association  ID  is  a  fixed  4-bytc  field  diat  “defines  a  cooperative  relationship 
between  NEU’s.”  NEU  A  and  NEU  B  share  cryptographic  keying  information  and  security 
managmnent  objects  represented  by  the  security  association  ID.  The  SCC  MDF  is  a  10-byte 
field  “defined  to  allow  the  transfer  of  information  that  may  facilitate,  but  is  not  required  for, 
the  processing  of  the  PDU.”  The  first  byte  is  the  SCC  MDF  version.  Byte  two  is  used  to 

die  confidentiality  algorithm  (CA)  and  die  integrity  check  value  algoiidim  (ICVA) 
used  to  encrypt  PNNI.  The  remaining  bytes  (3  through  10)  represent  an  initialization  vector, 
of  loigdi  8-bytes  used  by  DES  CBC. 
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NEU  A  places  a  ‘^protected  header”  as  well  as  additional  information  required  to  perform 
cryptographic  mtegrity  checks  into  the  data  portion  of  PNNI.  The  information  in  the 
protected  header  is  used  for  source  authentication  and  other  header  integrity  checks.  It 
includes  the  following  fields  extracted  from  the  clear  IP  header  of  PNNI :  source  address, 
version,  header  lengdi,  total  length,  fragmentation  flags,  time  to  live,  protocol,  and  the  header 
check  sum.  Crypto  pad  and  crypto  pad  length  fields  are  placed  after  the  data,  and  finaUy  an 
8-byte  integrity  check  value  GCV)  is  placed  at  the  end  of  the  packet  The  ICV  is  computed 
prior  to  packet  encryption  during  DBS  CBC.  All  data  after  the  IP  header,  excluding  the 
security  association  ^  and  the  SCC  MDF,  is  encrypted. 

The  NEU  supports  fragmentation  and  reassembly  of  packets  that  exceed  the  maximum 
(1500  bytes)  data  length  for  IEEE  802.3  frames;  fragmentation  is  performed  prior  to  packet 
encryption  as  specified  by  IEEE-STD-802.10B.  If  fragmentation  occurs,  NEU  A  will  also 
place  a  fragment  ID  field  into  the  protected  header. 

NEU  A  passes  the  encrypted  PNNI  onto  the  Ediemet  LAN  for  forwarding  by  the  router.  The 
router  interprets  the  unencrypted  IP  header  information  and  forwards  PNNI  to  NEU  B  to  be 
decrypted.  NEU  B  determines  the  DES  key  to  use  for  decrypting  PNNI  based  upon  the 
security  association  ID.  When  decrypting,  NEU  B  performs  source  authentication  by 
comparing  the  decrypted  protected  source  address  with  that  received  in  die  unencrypted  IP 
packet  header.  A  data  integrity  check  is  also  performed  by  NEU  B  in  which  the  ICV  is 
recomputed  on  die  decrypted  data.  If  there  is  a  mismatch  of  protected  source  address  or  ICV 
data,  the  packet  is  discarded.  Packets  (including  fragmoits)  received  by  NEU  B  are 
decrypted  and  reassembled  into  the  exact  format  as  originally  received  by  NEU  A.  NEU  B 
must  queue  and  reassemble  all  IP  fragments  before  forwarding.  The  decrypted  packet  PNNI 
is  forwarded  from  NEU  B  to  PNNIB  in  its  original  format 


2,8  NEU  OPERATIONAL  MODES 

The  following  items  are  selectable  from  the  front  panel  of  the  NEU:  Zeroize  (erases  all 
cryptographic  and  other  operating  parameters),  bypass  (all  data  will  be  bypassed  through 
the  NEU,  no  ciphering  of  data),  cipher  (encrypting,  bypassing,  or  blocking  data  based  iqxm 
die  access  control  table  configuration).  Signal  Quality  Error  T^est  (SQET)  on  or  off  (de&ulted 
to  off,  set  to  an  as  required  basis  by  host),  and  self-test  (a  diagnostics  program  to  test  all 
internal  circuitry  and  operational  parameters  and  test  failures  denoted  by  an  oror  message 
number). 

Access  to  operational  modes  from  the  front  panel  requires  a  programmed  Front  Panel 
Key  (FPK)  or  an  operational  dlK.  The  FPK  must  be  prograiraned  at  the  NSC.  Two 
push  buttons  on  the  front  panel  of  the  NEU  are  provided  for  viewing  and  selecting  items. 
Pressing  the  m«iu  button  will  cycle  through  the  choices,  pressing  the  select  button  displays 
options  for  each  item,  and  pressing  both  buttons  will  invoke  die  selected  operation  or  change 
die  selected  parameter. 
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SECTION  3 


ASSESSMENT  TESTING 


The  primary  objective  of  assessment  testing  was  to  examine  the  Semi^hore  NSS  in  an 
existing  operational  network.  Specifically,  the  NSS  was  integrated  into  the  INFOSEC  Cote 
Laboratory  to  examine  product  usability  by  paforming  interoperability  and  system 
pofonnance  testing.  Tests  were  devis^  to  maximize  dte  opeiadonal  capability  of  the  NSS; 
interoperability  tests  incorporated  other  network  devices  (i.e.,  bridges  and  routers)  and  NSS 
network  protocol  support;  system  performance  tests  included  data  throughput  measurements 
at  the  fqiplication  level.  The  base  test  network  configuration  is  depicted  in  Figure  8. 


Figures.  Base  Test  Network  Configuration 


3.1  INTEROPERABILITY  TESTS 

Interoperability  testing  aiKl  coexistence  testing  were  conducted  between  standard  network 
conq)onaits  (i.e.,  DEC  LAN  bridge  and  Qsco  Gateway)  to  examine  NEU  protocol  support 
for  TCP/IP,  AppleTalk,  and  Novell  IPX  protocols,  respectively.  Host  types  included  in  this 
test  were  Sun  Workstations,  MACs,  and  PC  AT  compatibles.  Where  applicable,  tests  results 
are  indicated  by  PASS  or  FAIL.  Unexpected  failures  are  noted. 
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1.  TCP/IP  protocol  support: 


Configure  two  NEUs  for  ciphered  network  communication  between  two  Sun 
w(nkstations.  Perform  Telnet  and  file  transfers  between  the  two  Sun  hosts  across  LAN 
components  and  observe  encrypted  packets  on  the  network  via  a  network  monitor  for  the 
following  cases: 

a.  Establish  connection  fit)m  Sun  1  host  to  Sun2  host  across: 

1.  Local  Sulmet  -  PASSED  as  expected. 

2.  Different  Subnets  across  DEC  LAN  Bridge  and  Qsco  gateway  -  PASSED  as 
expected. 

b.  Establish  Telnet  connection  from  Sun  1  host  to  Sun2  host  across: 

1.  Local  Subnet  -  PASSED  as  expected. 

2.  Different  Subnets  across  DEC  LAN  Bridge  and  Qsco  gateway  -  PASSED  as 
expected. 

2.  AppleTalk  protocol  support  (current  units  only  support  AppleTalk  encipherment  at  the 
data  link  layer  only): 

Configure  two  NEUs  for  ciphered  network  communication  (at  die  link  layer)  between 
two  Macintosh  computers.  Establish  an  AppleShare  connection  between  the  two 
computers  across  LAN  components,  and  observe  encrypted  packets  on  the  network  via  a 
network  monitor  for  the  following  cases: 

a.  Initiate  an  AppleShare  connection  from  MACl  to  MAC2  •  Failed  Unexpected. 

b.  Initiate  an  AppleShare  connection  from  MAC2  to  MACl  -  Failed  Unexpected. 

Note:  Unexpected  failure  was  due  to  a  faulty  LAN  ad^ter.  When  the  AppleShare 
connection  was  initiated  in  eitiier  direction,  Ae  NEU  protecting  MACl  failed  after  30 
to  60  seconds.  The  NEU  failure  was  indicated  by  an  audible  alarm  and  cycling  error 
codes  across  its  liquid  crystal  display  (LCD).  The  faulty  NEU  was  returned  to 
Semaphore  for  repair. 

3.  Novell  IPX  protocol  support: 

Configure  two  NEUs  for  ciphered  network  communication  between  the  DOS  PC  Novell 
client  and  the  saver.  Establish  a  NetWare  connection  between  Novell  Client  and  Server 
PC’s  across  LAN  components  and  observe  encrypted  packets  on  the  network  via  a 
network  monitor  for  the  following  cases: 
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a.  Copy  a  DOS  file  fi-om  a  PC  server  to  PC  client  across: 

1.  Local  subnet  -  not  tested. 

2.  Different  Subnets  across  DEC  LAN  bridge  and  Cisco  gateway  -  not  tested. 

Note:  Novell  client/server  testing  will  be  performed  upon  arrival  and  installation  of 
Novell  NetWare  software  (Version  4.0). 


32  THROUGHPUT  AND  PERFORMANCE  TESTS 

Throughput  and  performance  tests  were  conducted  across  various  network  components 
(i.e.,  host,  bridges,  and  gateways).  Host  types  were  Sun  workstations  and  the  network 
protocol  tested  was  Sun  TCP/IP.  A  netwo^  general  sniffer  and  Hewlett-Packard  (HP)  LAN 
analyzer  were  utilized  to  generate,  collect,  and  monitor  data.  NEU  sensitivity  to  packet  size 
and  interframe  delay  was  tested,  and  performantx  measurements  were  collected  at  the 
i^rplication  level  in  bytes  per  second. 

1.  Throughput  Test:  Packet  Size  and  Inteiframe  Delay  Sensitivity 

Set  up  traffic  goierator  and  LAN  analyzer  to  collect  throughput  measurements  as  shown 
in  Figure  9.  For  varied  frame  sizes,  adjust  the  delay  time  between  Ethernet  frames  to 
increase  the  throughput  For  each  frame  size  in  bytes  (46, 60, 576, 1024, 1400, 1460,  and 
1514),  collect  clear  text  throughput  data  and  dien  encrypted  throughput  measurements. 
Frame  sizes  and  maximum  throughput  values  observed  are  recorded  in  Table  1. 


Figure  9.  NEU  Throughput  Test  Ck)nfiguration 
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Maximum  Throughput  Observed 

Selected 

Actual 

Fnmts/Scc  Kbit/Scc 

46 

Collisions  Observed  (Illegal  Packet  Size)  I 

60 

104 

4167 

3867 

576 

616 

1861 

9345 

1024 

1064 

1105 

9513 

1400 

1440 

823 

9576 

1460 

1504 

769 

9330 

1514 

Ragmentation 

— 

1  Note:  NEU  firagmoitation  firk  obsoved  at  1476  E 

lytes 

Table  1.  Throughput  Rates 


2.  Performance  at  the  Network  Application  Level: 

a.  TCP/IP  Test  File  transfer  rates  between  Sun  Workstations  using  FTP. 

1.  Conflgure  Sunl  behind  NEU 1  and  configure  Sun2  behind  NEU2  on  LAN 
across  bridge  and  gateway  as  shown  in  Hgure  10. 

•  Set  up  directory  of  ten  files  ranging  in  file  size  (22  to  2,0(X),(XX)  bytes). 

•  Establish  an  ftp  session  betweoi  Sunl  and  Sun2. 

•  Transfer  directory  of  files  ten  times  using  mput  then  ten  times  using  mget 
between  Sunl  and  Sun2  in  clear  text,  and  then  repeat  identical  file  transfers 
encrypted  across  NEU. 
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Figure  10.  NEU  Network  Configuration  for  File  Transfers  Across  Bridge  and  Gateway 


•  Average  transfers  rates  for  each  file  size  are  recorded  in  Tables  2  and  3. 


I  12  3EE3S  fiiSSl 

■ 


P’^Size  I  Avg  Total  Number  of  SecondsI  Ave  KBvtes  Per  Second 
I  QwText 


100594 


355220 


662528 


1015808 


23592961  3.46 


Table  2.  mput  File  Transfers  Rates  Across  LAN  Bridge  and  Cisco  Gateway 
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Table  3.  mget  File  Transfers  Rates  Across  LAN  Bridge  and  Cisco  Gateway 


Table  3a.  Graph  of  mget  File  Transfers  Rates  Across  LAN  Bridge  and  Cisco  Gateway 
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Trials  in  Tables  3  through  5  were  derived  using  default  Sun  TCP  parameters.  However,  total 
transfer  times  (across  the  NEU)  were  observed  to  improve  by  approximately  one-third  to 
one-fourth  of  the  times  indicated  in  each  table  when  specific  TCP  parameters  were  modified. 
For  example,  in  Table  4,  the  total  file  transfer  time  in  seconds  for  ^e  2.3  MB  file  is 
93  seconds.  Reduction  of  the  TCP  retransmit  threshold  parameter  from  three  to  one  reduced 
this  average  file  transfer  rate  from  93  to  24  seconds.  Maximum  file  transfer  rates  through 
the  NEU  were  observed  using  a  modified  TCP  maximum  segment  size  of  1400  bytes  across 
different  subnets. 

On  a  local  subnet.  Sun  workstations  ignore  the  TCP  maximum  segment  size  when 
transmitting  data  and  the  default  maximum  segment  size  (observed  at  1460)  or  a  negotiated 
size  is  used.  Because  additional  information  is  added  to  each  packet  by  the  NEU, 
firagmentadon  results  on  the  black  side  of  the  NEU.  Slow  reassembly  of  fi'agmented  packets 
by  the  NEU  additionally  causes  retransmissions  of  packets  by  the  host  The  combination  of 
delays  due  to  NEU  fragmentation  and  host  retransmissions  significantly  reduces  throughput 
and  total  transfer  times. 

2.  Reconfigure  Sunl  and  NEUl  to  reside  on  the  same  local  subnet  as  Sun  2  and  NEU2  as 
shown  in  Figure  11. 


Figure  1 1.  NEU  Test  Configuration  for  File  Transfers  Between  Suns  on  the  Same  Subnet 


3.  Display  graphics  across  XTERM  connection  between  Suns  in  clear  text  and  then 
encrypt  by  NEU  as  shown  in  test  configuration  Figures  3  and  4. 
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Rq)eat  steps  for  test  number  one  above.  Average  transfer  rates  for  mputs  and  mgets  are 
recorded  in  Tables  4  and  5. 


File  Size 
Bytes 

mput  1 

Avg  Total  Number  of  Seconds 

Avg  KBytes  Per  Second  | 

QearText 

NEU 

Gear  Text 

NEU 

.001 

.001 

379 

414 

1005 

.001 

.001 

772 

766 

5437 

.002 

.003 

2080 

2120 

20170 

.009 

.009 

2093 

2310 

49789 

.041 

7.12 

1200 

40.92 

100594 

.105 

16.24 

925 

32.08 

355220 

.472 

31.90 

735 

26.11 

662528 

.908 

51.70 

712 

26.76 

1015808 

1.37 

56.70 

723 

31.10 

2359296 

3.16 

93.90 

73' 

24.60 

Table  4.  mput  Transfers  Rates  Between  Suns  on  Same  Subnet 


•o-dear 
-A-  neu 


Table  4a.  Graph  of  mput  Transfers  Rates  Between  Suns  on  Same  Subnet 


Table  S.  mget  Hie  Transfers  Rates  Between  Suns  on  Same  Subnet 
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Actual  and  graphic  transfer  rates  for  10  samples  each  are  recorded  in  Tables  6  and  7. 


Total  Frames 

Frames  Per  Second 

Total  Seconds 

QearText 

NEU 

NEU 

Qear  Text 

NEU 

.4906 

.4823 

9.62 

5.92 

57.84 

94.16 

.4882 

.4742 

9.64 

5.22 

57.78 

106.76 

.4876 

.4876 

9.64 

4.87 

57.75 

114.31 

.4883 

.4771 

9.64 

5.48 

57.80 

101.56 

.4879 

.4792 

9.65 

5.19 

57.70 

107.38 

.4882 

.4807 

9.67 

5.45 

57.59 

102.20 

.4874 

.4839 

9.66 

5.59 

57.68 

99.64 

.4887 

.4811 

9.68 

5.40 

57.51 

103.15 

.4874 

.4846 

9.66 

5.08 

57.65 

109.60 

.4874 

.4809 

9.67 

5.22 

57.60 

106.61 

Table  6.  Data  Points:  mjackson.mpg  (724576  bytes)  Across  Bridge  and  Gateway 
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Total  Frames 


Frames  Per  Second 


Total  Seconds 


QearText 

NEU 

NEU 

QearText 

NEU 

.4854 

.7189 

11.13 

1.74 

50.05 

319.90 

.4851 

.7227 

11.19 

1.78 

49.77 

312.52 

mmm 

.7192 

11.13 

1.74 

50.02 

320.36 

.7461 

11.16 

5.92 

49.92 

94.09 

.4844 

.7201 

11.13 

1.75 

50.01 

317.76 

.4843 

.7207 

11.17 

1.75 

49.86 

316.49 

.4850 

.7213 

11.18 

1.80 

49.83 

308.71 

.4853 

.7233 

11.22 

1.75 

49.67 

318.06 

.AMI 

.7486 

11.17 

3.27 

49.84 

169.91 

.4848 

.7442 

11.16 

5.94 

49.90 

93.70 

Table  7.  Data  Points:  mjackson.mpg  (724S76  bytes)  Betweoi  Suns  on  Same  Subnet 
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SECTION  4 


SUMMARY  OF  TEST  RESULTS 


The  siunmary  of  test  results  are  grouped  into  four  categories  that  were  derived  from  areas  of 
concern  based  upon  test  observations.  Test  categories  are  performance  and  throughput, 
hardware  reliability,  installation  and  maintenance,  and  user  documentation. 


4.1  PERFORMANCE  AND  THROUGHPUT 

The  raw  throughput  rates  observed  during  testing  were  consistent  with  the  Seimyrhore- 
projected  rates  of  9  MBits/Sec  (800  packets/sec).  However,  the  rqrplication-level  data 
transfer  rates  observed  were  inconsistent  and  unpredictable.  Software  configurations  were 
adjusted  on  Sun  workstations  to  maximize  file  transfer  rates;  this  involved  adjustment  to 
TCP  maximum  segment  size  and  retransmission  threshold  parameters.  Adjustments  did 
improve  throughput,  but  rates  remained  inconsistent 

Inconsistent  and  often  slow  file  transfer  rates  (as  described  by  Semaphore)  were  due  to 
restricted  buffer  sizes  of  the  NEU  in  conjunction  with  the  NEU  firagmmtation  reassembly 
process.  When  receiving  fragmented  packets,  the  NEU  reassembly  process  was  too  slow  to 
keep  up  with  the  volume  of  ^gments  received.  As  a  result,  retransmission  of  packets 
occurred  from  the  source.  Packet  retransmissions  increased  with  NEU  packet  fragmentation. 
Semaphore  claims  to  have  addressed  fiiese  problems  in  the  next  release  of  its  products. 
Additional  buffer  space  will  be  available  with  the  replacement  of  the  current  memory  chips. 
The  speed  of  die  NEU  fragmentation  reassembly  process  will  also  be  improved. 


4J  HARDWARE  RELUBILITY 

Hardware  problems  were  uncovered  during  testing.  Each  of  the  original  test  units  wore 
observed  to  fail  if  disconnected  from  the  network  for  some  short  (but  undetermined)  period 
of  time.  These  units  were  replaced  with  newo*  ones  containing  fimware  upgrades  that 
corrected  the  failure.  Subsequently,  attempts  to  configure  AppleTalk  encipherment  (link 
layer  only)  failed  due  to  a  faulty  LAN  ddapvet  in  one  of  the  l^Us.  This  failure  occurred  only 
during  attnnpts  to  initiate  Aj^leTalk  network  connections.  The  faulty  unit  was  returned  to 
Semaphcne  for  iqiair.  Senuqihore  addressed  hardware  problems  by  rqilacing^reiKuring 
equipment  with  minimal  turnaround  and  downtime. 


43  INSTALLATION  AND  MAINTENANCE 

Physical  installation  of  the  lightweight  NEU  was  simple  and  fast  Out  of  die  box.  basic 
installation  includes  placement  of  batteries,  plugging  into  an  outlet,  and  cminecting  network 
cables.  All  initial  configuration  was  perfon^  at  the  NSC  Initializatimi  of  each  NEU  was 
started  by  inserting  and  removing  (sqiproximately  two  secoiuls)  its  programmed  initialization 
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key.  Conviction  of  initialization  takes  a  couple  of  minutes  and  occurs  across  the  network. 
TIk  NSC  and  NEU  must  exchange  authentication  information.  The  NSC  downloads 
configuration  data  to  the  NEU.  Once  operational,  maintenance  is  minimal;  a  good  battery  is 
the  primary  concern  in  case  of  power  loss.  However,  the  establishment  of  a  practical 
maintenance  and  security  policy  is  recommended.  Maintenance  software,  such  as  Self-test 
and  diagnostics,  is  available  via  the  NEU  front  panel.  Access  is  protected  by  requiring  the 
insertion  of  a  progranuned  FPK  or  CDC. 


4.4  USER  DOCUMENTATION 

Issues  with  the  produa  documentation  were  a  concern.  Although  satisfactory  for  initial  and 
basic  TCP/IP  configurations,  the  documentation  was  determined  to  be  incomplete  and 
unsatisfactory  for  administering  other  tasks,  such  as  configuring  for  link  level  encryption. 

In  particular,  there  were  no  instructions  available  for  configuring  AppleTalk  or  any  of  the 
link-level  protocols.  The  documentation  also  cited  product  function^ty  as  if  it  were 
currently  available  for  use,  whereas  it  is  not  Additionally,  the  user-friendly  configuration 
menus,  although  straightforward  and  easy-to-use,  were  found  to  be  tedious  and 
time-consuming.  Deficiencies  found  in  the  documentation  and  configuration  menus  are 
being  corrected  in  conjunction  with  enhancements  of  soon-to-be-released  products. 
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SECTIONS 


FUTURE  WORK 


Effective  resolution  of  issues  described  in  section  4  were  expected  with  the  release  of 
Semaphore  site  units  (NEU-RT  and  NEU-ST).  The  site  units  will  have  added  functionality 
diat  is  more  applicable  to  current  needs.  In  addition  to  site-to-site  network  protection, 
support  for  Frame  Relay,  SNMP,  and  AppleTalk  routing  (the  NEU-WG  test  units,  model 
3013,  support  AppleTalk  at  the  link  layer  only)  will  be  available  in  these  new  product 
releases.  The  new  and  improved  NEU-WG  inodel  3013A  is  currently  available  and 
addresses  die  performance  and  fragmentation  problems  uncovered  during  testing. 

Semaphore  asserts  that  performance  is  significantly  improved  with  the  new  units. 

Semaphore  has  also  proposed  the  development  of  a  board-level  version  of  the  NEU  for 
placement  into  a  host  con^uter.  The  schedule  for  development  and  release  of  the  board-level 
product  is  undetermined  at  this  time. 

The  primary  focuses  of  this  preliminary  examination  of  the  NEU-WG  unit  were 
interoperability,  performance,  and  ease  of  use.  Future  integration  testing  is  recommended  for 
die  new  Senuqihoie  products  that  will  more  closely  fit  our  sponsors’  needs.  At  that  time,  it  is 
recommended  that  network  security  vulnerabilides  (i.e.,  replay)  and  security  features  be  more 
closely  examined.  Performance  tests  should  also  be  rerun  on  the  new  and  improved  units. 
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LIST  OF  ACRONYMS 


ANSI 

American  National  Standards  Institute 

AUI 

Attachment  Unit  Interface 

CA 

Confidentiality  Algorithm 

CBC 

Cipher  Block  Chaining 

OK 

Cryptographic  Ignition  Key 

COI 

Community  of  Interest 

COTS 

Commercial-off-the-shelf 

DEC 

Digital  Equipment  Corporation 

DES 

Data  Encryption  Standard 

DOD 

Department  of  Defense 

FPK 

Front  Panel  Key 

HP 

Hewlett-Packard  Company 

IBM 

International  Business  Machines 

ICV 

Integrity  Check  Value 

ICVA 

Integrity  Check  Val”2  /Jgorithm 

ID 

Identification 

IEEE 

Institute  of  Electrical  and  Electronics  Engineers,  Inc. 

INFOSEC 

Information  Security 

INK 

Initialization  Key 

IP 

Internet  Protocol 

IPX 

Inter-Networic  Pack  Exchange 

ISO 

International  Standards  Organization 

LAN 

Local  Area  Network 

LCD 

Liquid  Crystal  Display 

MAC 

Macintosh 

MB 

Megabyte 

MBits 

Megabits 

MDF 

Management-Defined  Field 

mget 

multiple  get 

MHz 

Megj^ertz 

mput 

multiple  put 

NAK 

NSC  Access  Key 

NEU 

Network  Encryption  Unit 

NEU-HB 

Network  Encryption  Unit-Hub 

NEU-PC 

Network  Encryption  Unit-Personal  Computer 

NEU-RT 

Network  Encryption  Unit-Router 
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NEU-ST 

NEU-WG 

NSC 

NSS 

PC 

PC  AT 

PDU 

PNN 

RAM 

RISC 

RSA 

SQET 

STD 

SVGA 

TCP 

TEK 


Netwoik  Encryption  Unit-Site 
Network  Encryption  Unit-Work  Group 
Network  Security  Center 
Network  Security  System 

Personal  Conq)uter 

Personal  Con^uter  Advanced  Technology 
Protocol  Data  Unit 
Protected  Network  Node 

Random  Access  Memory 
Reduced  Instruction  Set 
Rivest,  Shamir,  and  Adleman 

Signal  Quality  Error  Test 
Standard 

Super  Video  Graphics  Adaptor 

Transmission  Control  Protocol 
Traffic  Encryption  Key 


XTERM 


X-Windows  Terminal 


